An Exception is an anomalous event that occurs during the runtime of a program and disrupts the normal flow of instructions. Many kinds of errors can cause software exceptions—problems ranging from resource unavailability like “File not found” to programming errors, such as trying to access an out-of-bounds array element. For example, in an object-oriented programming environment, an exception may occur when a particular object fails to operate in an expected manner. Without proper handling of the exception, the computer program may produce unexpected results and, moreover, may abruptly halt execution of the program. However, a skilled computer programmer is likely to account for such an exception via code, which services or handles the exception. This exception handling code also cleans up the memory used by an object. Thus, the program is able to use the exception handling code to recover from the failure and continue proper execution of the program or terminate gracefully.
Runtime errors or exceptions may be handled by in-built mechanisms provided by the programming language. Using a built-in exception-handling scheme, the exception is typically handled by code outside the normal flow of execution. Object oriented programming languages provide an exemplary built-in scheme for handling runtime errors or exceptions. In such languages the compiler implements exception handling using a TRY/CATCH paradigm. Essentially, a TRY statement is followed by a section of code where an exception may occur during execution of the code section. The process of raising an exception when the exception occurs in this code section is generally called “throwing” the exception. The “thrown” exception is “caught” or handled by a CATCH block of exception handling code. Within the CATCH block of code, the programmer can write code to take appropriate actions for handling the exception. This could include clearing memory associated with an object, which is no longer in use.
Exception handling schemes such as the TRY/CATCH approach are easy for computer programmers to implement. Computer programmers are able to take advantage of built-in exception handling schemes without having to spend time writing additional code to handle runtime errors or exceptions. These languages support a set of predefined exceptions. In addition to these predefined exceptions, the user can also define new exceptions during program development that get bound at compile time. The crucial thing about all these exceptions is that the exception types as well as their handlers have to be defined at compile time and cannot be changed later.
Object oriented programming languages like Java and C++ also support a mechanism to override methods and classes. A subclass can override a method in its super class by defining a method with the same name, return type, number and type of the parameters as that of the method in the super-class. This technique can be used to extend the functionality of the exception handlers by defining new methods/classes that override the exception handler code. If the overriding method/class can be declared and loaded at runtime then this gives the flexibility to alter the behavior of the program at runtime as per the application's need.
Current exception mechanisms require that all the types of exceptions that may occur during the execution of the program be known a priori at compile time. The error handling code is also defined at compile time, which precludes changing the error-handling behavior later at runtime.
“A study of the Applicability of Existing Exception-Handling Techniques to Component-Based Real-Time Software Technology” published in ACM Transactions on Programming Languages and Systems, Vol. 20, No. 2, March 1998 (pp. 274–301), discusses a strategy for error handling for component based real-time systems. The paper proposes a decentralized approach towards exception handling. However the paper has the limitation that the techniques described therein would either require an operating system support or a modification to the programming language thereby limiting the applicability.
U.S. Pat. No. 6,247,169 describes a structured exception-handling mechanism. The invention wraps the software code with one or more exception handling constructs that can be nested. In case the exception is not defined in the constructs then a provision for default handler outside the scope of the exception code is provided. The invention describes a language dependent architecture and also decouples the exception-handling behavior by providing a default exception beyond the lexical scope of the encapsulated code. It can not be used to customize the exception-handling behavior at run-time.
U.S. Pat. No. 6,282,636 provides a decentralized exception processing system for hardware. The patent describes a methodology wherein one or more local exception unit generates exception signals that are combined to generate global exceptions by a global unit. Though this patent does talk about decentralizing the exception handlers but total decoupling is not achieved as all local units report back to the global unit.
With the current set of programming languages, the exception types and handlers are tightly coupled at compile time, with the exception handling code being hard coded into the application. Not surprisingly, exception handlers and the program itself are implemented in the same language. Due to the tight coupling of the handlers with the program code, dynamic exception handling, i.e., specifying exception types and exception handler at runtime, has not been supported in any application or programming language. In this sense the behavior of the program is fixed at compile time.
However, in many situations there is a need to extend or change the behavior of the exception handler. This entails rewriting the exception handler code. This requires code maintenance and is not always feasible as the code may be from a legacy system or may not be available. The only way to change the exception handler behavior is to change the code, which requires recompilation of the code. Hence there is a need for a mechanism that changes the exception-handling behavior of the system at runtime that does not require code modification thereby overcoming the limitation of programming language support.
Hence there is a need for a mechanism for dynamic exception handling to solve the aforementioned problems. Some scenarios that exemplify the value of dynamic exception handling are:                a) Suppose one wants to tailor the behavior of a legacy component of an application to a new deployment domain. An example could be from a banking system that was so far used only by its employees and is now being deployed over the web, enabling direct access to the customers. The banking application could have a Customer Transaction module, which throws exceptions like “File locked exception”. “Invalid access” etc. When the application is moved to the web then these exceptions should be mapped to more meaningful exceptions like “Account currently not available—please try later”, “Maximum draft amount is 25,000” etc.        b) An online trading application could use different modules like credit card authorization module, inventory module etc. The credit card authorization module can throw various kinds of exceptions like “Invalid card number”, “Card expired”, “Transaction amount failure”, “Invalid card expiry date” etc. Exposing the user to these exceptions will not be advisable from the security point of view. Hence the exception returned to the user should be non-committal rather than giving specific information about the type of the exception. Therefore there is a need to mask these exceptions into a single exception like “Credit Card Authorization Failure”. In this way the credit card authorization module (provided by the credit card Company) can be reused in different applications by masking the exceptions as per the requirements of the application.        c) A different scenario is when an application has to be internationalized—i.e. made available in multiple languages. Here, the error messages may have to take into account the nuances of the target language or cultural differences in the expression. Hence, in such a scenario, the exceptions that are thrown by the application will have to be masked to a different exception depending on the type of language selected by the user.        d) Consider a distributed workflow. When a module raises an exception that it cannot handle, the exception is reported back to the workflow manager (initiator) who handles the exception and then restarts/resumes the workflow. Using dynamic exception handling, it is possible to enhance the capability of the module to handle the exception it was not designed to, and resume the workflow without the explicit intervention of the workflow manager. This improves the performance and throughput of the distributed system.        
All the above examples illustrate the need to change/extend the behavior of a program at runtime.